Implementing  the  TILT  Internal  Language 


Leaf  Petersen,  Perry  Cheng,  Robert  Harper,  and  Chris  Stone. 

December,  2000 
CMU-CS-00-180 


DISTRIBUTION  STATEMENT  A 

Approved  for  Public  Release 
Distribution  Unlimited 


School  of  Computer  Science 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 


Abstract 

The  TILT  compiler  for  Standard  ML  represents  programs  internally  using  a  predicative  lambda 
calculus  based  on  Girard’s  Fw.  At  the  kind  level,  this  language  is  notable  for  containing  singleton 
kinds  and  dependent  product  and  function  kinds.  Previous  work  [SH99]  established  the  decidability 
of  type  equivalence  for  this  language. 

This  paper  presents  a  typechecking  algorithm  for  the  full  TILT  internal  language  and  discusses 
some  of  the  more  interesting  features  of  the  language.  The  particular  use  of  intensional  type 
analysis  to  handle  arrays  of  unboxed  floating  point  numbers  is  described.  An  extended  calculus 
is  also  introduced  which  permits  unlabelled  singletons  at  higher  kind,  in  order  to  allow  for  more 
compact  program  representation.  The  extended  calculus  is  related  to  the  restricted  calculus  via  a 
transformation  that  eliminates  the  unlabelled  singletons,  and  the  decidability  of  the  typechecking 
algorithms  for  both  the  original  and  extended  calculus  is  shown. 
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Introduction 


1.1  Background 

The  past  years  have  seen  a  great  deal  of  interest  in  the  idea  of  “typed  compilation”:  that  is, 
maintaining  type  information  throughout  the  compilation  process.  This  type  information  can  be 
exploited  by  the  compiler  internally  to  allow  for  optimized  data  representations  and  to  do  tag-free 
garbage  collection,  as  well  as  providing  the  compiler  with  a  basis  for  internal  correctness  checks. 
This  work  was  pioneered  in  the  TIL  compiler  at  CMU  [TMC+96].  Other  recent  work  has  also 
suggested  the  possibility  of  maintaining  type  information  through  to  the  machine  code  as  a  form 
of  certification  [MWCG97]. 

The  TIL  compiler  clearly  demonstrated  that  typed  compilation  was  both  feasible  and  desirable. 
However,  TIL  compiled  only  the  core  language  of  Standard  ML:  the  powerful  modular  features 
that  are  one  of  the  most  important  elements  of  SML  were  not  dealt  with.  The  TIL  Two  (TILT) 
compiler  was  aimed  at  addressing  this  shortcoming. 

The  TILT  architecture  is  based  around  two  typed  intermediate  languages.  The  initial  elabora¬ 
tion  from  SML  source  targets  a  structures  calculus  called  the  HIL  (High  Intermediate  Language). 
This  language  is  relatively  close  to  SML,  and  among  other  things  provides  the  interface  language 
used  for  separate  compilation.  After  elaboration  (and  hence  typechecking),  the  HIL  is  translated  to 
a  second  typed  language  called  the  MIL  (Middle  Intermediate  Language)  through  a  process  called 
phase  splitting  [HMM90].  The  phase  splitting  process  maps  each  SML  structure  into  separate  type 
and  term  level  records,  representing  the  static  and  dynamic  portions  of  the  structure.  Similarly, 
SML  functors  are  mapped  to  type  and  term  level  functions.  In  this  fashion,  modular  programs  are 
translated  into  programs  containing  only  lambda  calculus  terms. 

We  will  not  address  the  details  of  phase  splitting  here,  except  to  note  that  serving  as  a  target  of 
this  translation  is  the  primary  motivation  for  the  type  theory  of  the  MIL.  The  MIL  must  be  able  to 
express  within  a  single  lambda  calculus  all  of  the  constructs  of  both  the  module  language  and  the 
core  language.  Singleton  kinds  are  used  to  express  type  definitions  in  signatures,  and  dependent 
product  and  function  kinds  serve  to  express  signatures  which  contain  definitions  in  terms  of  previous 
fields. 

The  MIL  is  also  the  language  in  which  almost  all  of  the  optimization  passes  are  done.  This 
constrains  the  design  of  the  MIL,  since  it  must  be  possible  to  express  the  results  all  of  the  desired 
optimizations  in  a  typed  fashion.  In  particular,  it  is  important  that  the  necessary  primitives  for 
data  representation  optimizations  be  present  at  this  level. 


1.2  Overview 

This  paper  gives  a  detailed  overview  of  the  MIL  largely  as  implemented  in  the  TILT  compiler.  The 
major  omission  is  that  closure  conversion  and  the  typing  of  closures  is  not  treated  here. 

In  [SH99],  Stone  and  Harper  present  an  algorithm  for  deciding  type  equivalence  in  a  lambda 
calculus  with  singleton  kinds.  Section  2  of  this  paper  describes  the  extension  of  this  calculus  to 
the  full  MIL  language.  Design  issues  motivating  the  extensions  are  discussed,  and  algorithms  for 
typechecking  are  given  along  with  proofs  of  termination. 

Section  3  addresses  a  major  practical  shortcoming  of  the  MIL:  the  inability  to  represent  kinds 
compactly.  We  present  an  extended  calculus  called  the  NIL  which  addresses  these  shortcomings 
by  providing  unlabelled  singletons  at  higher  kind.  The  MIL  algorithms  and  proofs  are  extended  to 
the  NIL. 
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The  main  technical  results  of  the  paper  are  the  creation  of  an  algorithm  for  deciding  typechecking 
in  a  language  with  unlabelled  singletons  at  higher  kind,  and  the  proofs  of  the  decidability  of 
typechecking  in  both  the  core  and  the  extended  system. 

Appendices  A  and  B  contain  the  full  static  semantics  for  the  MIL  and  NIL,  respectively. 


2  Mil 

2.1  Relation  to  A<ES 

The  constructor  and  kind  level  of  the  MIL  has  been  studied  separately  by  Harper  and  Stone  [SH99] . 
That  paper  presented  a  core  MIL-like  language  called  A<ESand  gave  an  a  sound  and  complete 
algorithm  for  determining  constructor  equivalence. 
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Figure  1:  A<E5Syntax 

The  syntax  of  the  A<E5  calculus  is  given  in  figure  1.  This  calculus  makes  up  the  core  of  the  MIL 
language  discussed  here.  The  major  type  theoretic  ideas  of  the  MIL  are  for  the  most  part  already 
present  in  A<ES.  From  a  practical  standpoint  however,  many  essential  components  are  missing 
from  A<ES:  in  particular,  A<ES  does  not  deal  with  the  term  level  structure  of  the  language.  This 
section  will  flesh  out  the  term  level  extensions  necessary,  and  will  discuss  their  typing  properties. 
The  kind  level  remains  unchanged  from  A<E5  to  MIL,  but  the  set  of  constructors  increases. 

2.2  Constructors  and  types 

The  syntax  for  the  constructor  and  kind  levels  of  the  MIL  is  given  in  figure  2.  In  contrast  to 
A<E5,  the  MIL  language  includes  base  constructors  such  as  Int  that  are  used  to  classify  terms. 
All  of  these  base  constructors  are  standard,  with  the  exception  of  the  use  of  the  known  sum  type, 
corresponding  to  the  type  of  a  sum  for  which  the  branch  inhabited  is  known. 

The  MIL  also  includes  an  explicit  let  construct,  although  technically  this  is  definable  in  the 
calculus  [SH99] .  Let  binding  provides  a  means  for  expressing  constructors  more  compactly,  as  well 
as  to  name  and  reuse  the  results  of  type  computations.  This  serves  both  to  help  make  compilation 
faster  and  to  improve  runtime  performance,  since  constructors  may  be  needed  at  runtime.  In  order 
to  reduce  the  size  of  programs,  we  elide  the  classifiers  on  the  let  bound  variables.  While  this 
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information  is  easily  reconstructed  from  the  definition  itself,  this  imposes  some  additional  work  on 
the  compiler. 

Also  given  in  figure  2  is  the  syntax  for  the  type  level.  Unlike  the  constructor  level  which 
corresponds  to  the  notion  of  types  as  data ,  the  type  level  in  a  predicative  system  corresponds  to  the 
notion  of  types  as  classifiers.  The  constructor  level  is  included  into  the  type  level  via  an  explicit 
inclusion  T(c).  The  type  level  also  contains  classifiers  for  polymorphic  functions,  unboxed  floating 
point  numbers,  and  pairs  of  terms.  The  duplication  of  the  the  pair  type  at  the  type  level  indicates 
the  possibility  of  constructing  pairs  containing  arbitrary  terms  (such  as  unboxed  floats)  which  is 
not  provided  for  by  the  constructor  level.  For  similar  reasons  a  constructor  let  form  is  also  included 
in  the  type  level  so  that  constructors  (but  not  types!)  can  be  bound  in  types. 

For  presentational  purposes,  the  static  semantics  of  the  MIL  calculus  is  initially  described  using 
a  straightforward  declarative  approach  which  is  more  easily  understood.  This  approach  does  not 
correspond  naturally  to  an  algorithm,  and  hence  it  is  will  be  necessary  in  subsequent  sections  to 
develop  an  equivalent  algorithmic  presentation  of  the  static  semantics.  The  complete  declarative 
static  semantics  for  the  MIL  language  is  defined  in  appendix  A.l,  but  for  the  most  part  this  section 
will  concentrate  on  the  key  non-standard  elements  that  make  the  MIL  theory  interesting. 


A  ok 
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A  h  Ki  ■<  K2 

A  h  Ci  =  C2  ::  k 
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Figure  3:  MIL  declarative  judgements 


The  judgements  used  to  define  the  MIL  static  semantics  are  described  in  figure  3.  In  addition 
to  the  expected  well-formedness  judgements,  there  is  also  a  sub-kinding  judgement.  The  presence 
of  singleton  kinds  means  that  a  constructor  may  have  multiple  kinds:  for  example,  the  judgements 
A  b  Int  ::  T  and  A  b  Int  ::  5j(/nt)  are  both  derivable  in  the  system.  The  sub-kinding  judgment 
reflects  the  fact  that  a  singleton  kind  gives  more  information  than  does  a  simple  kind,  and  hence 
should  be  viewed  as  a  subtype.  In  particular,  the  key  rule  from  the  sub-kinding  judgment  is  the 
singleton  rule: 

A  h  St{c ) 

_  SingletonL 

Ah  St(c)^T 

which  says  that  any  well-formed  singleton  kind  is  a  sub-kind  of  T.  The  sub-kinding  judgment  affects 
constructor  well-formedness  via  a  subsumption  rule 


A  b  c  ::  k  A  \~  k  -<  Kf 


A  h  c  ::  k' 


Subkind 


which  says  that  a  constructor  is  well-formed  at  kind  n  if  it  is  well-formed  at  a  subtype  of  k. 
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The  main  non-standard  typing  rules  are  the  extensionality  rules  and  the  self  rule  of  the  con¬ 
structor  well-formedness  judgement  [HL94].  The  self  rule  is  the  introduction  rule  for  singleton 
kinds,  and  says  that  any  constructor  c  which  is  well-formed  at  kind  T  is  well-formed  at  kind  5y(c). 

Aho::T 

_  Selfify 

A  he::  St(c) 

Accompanying  this  rule  are  the  extensionality  rules: 

A  h  c  ::  S(a  ::  Ki).K2  A  h  c.l ::  kJ 

-  SigmaExtl 

A  h  c  ::  ^(a  ::  k[).K2 

Ahc::  E(a  ::  Ki).k2  A  h  c.  2  ::  k2 

-  SigmaExt2 

A  h  e  ::  K]  x  n2 


Ahc::  n(o  ::  k\).k2  A[a::Ki]  h  ca  ::  k2 

_  PiExt 

Ahc::  n(ce ::  ki).k'2 

These  rules  essentially  extend  the  notion  of  the  self  rule  to  higher  kinds  via  eta-expansion:  that 
is,  they  allow  derivations  such  as  [a::Il(/3  ::T).T ]  ha::  IT(/?  ::  T).5r(a  0)  For  a  more  detailed 
discussion  of  these  rules  see  [SH99,  HL94]. 

2.3  Terms 

The  term  level  MIL  syntax  is  given  in  figure  4.  In  addition  to  the  standard  lambda  calculus 
constructs  the  MIL  also  provides  for  expression  and  constructor  let  bindings,  again  with  the  classifier 
elided  for  reasons  of  program  size.  Unlike  most  lambda  calculi  though,  the  MIL  also  includes  low 
level  data  representation  primitives  (such  as  float  boxing  and  unboxing  primitives).  In  addition  to 
serving  as  the  target  language  of  phase-splitting,  the  MIL  also  serves  as  the  object  of  most  of  the 
compiler  optimization  phases,  including  inlining,  common  subexpression  elimination,  and  function 
specialization.  These  optimizations  may  expose  opportunities  for  data-layout  optimization,  such 
as  eliminating  redundant  boxing  and  unboxing  of  floats  which  can  only  be  performed  if  the  boxing 
and  unboxing  operations  are  present  at  the  MIL  level. 

For  similar  reasons,  the  sum  case  construct  in  the  MIL  is  also  somewhat  non-standard,  as  can 
be  seen  from  the  sum  elimination  rule  [HS97]. 

Abe  :  T{c!  +  c2) 

A[x  :  T(ci +1  c2)]  h  ex  :  r  A[x  :  T(ci  +2  c2)j  h  e2  :  r  .... 

- -  bum  elimination 

A  h  caser  eof  (inl(x)  =>  ei,  inr(x)  =>  e2}  :  r 

Notice  that  the  case  construct  does  not  destructure  its  argument  -  rather,  it  will  bind  the  argument 
in  the  appropriate  branch  to  a  variable  whose  type  is  a  known  sum  indicating  the  inhabited  branch. 
The  known  sum  projection  construct  can  then  be  used  to  project  out  the  value  if  it  is  actually 
required  by  that  particular  branch. 

Abe  :  r  A  b-  r  =  T(c\  +*  C2) 

-  Known  sum  elimination 

A  h  projj(e)  :  T(c;) 
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Exps  e  ::=  x 
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Figure  4:  MIL  expressions 


2.3.1  Type  analysis 


A  key  optimization  that  the  original  TIL  compiler  implemented  was  the  use  of  non-uniform  data 
representation.  Many  implementations  of  languages  with  polymorphism  require  that  all  values  fit 
into  a  word.  In  particular,  array  elements  must  always  be  word-sized,  which  means  that  arrays  of 
64  bit  floats  (for  example)  must  actually  be  arrays  of  pointers  to  floats.  This  is  highly  undesirable, 
both  because  of  the  extra  pointer  indirections  implicit  in  each  lookup  and  because  of  the  consequent 
loss  of  data  locality. 

TIL  pioneered  the  use  of  intensional  polymorphism  to  avoid  this  overhead.  By  passing  types  at 
runtime  and  allowing  code  to  dispatch  on  them,  unboxed  floating  point  arrays  could  be  used  with 
the  appropriate  subscript  stride  chosen  at  runtime.  Different  pieces  of  code  could  be  run  based  on 
the  runtime  type  of  polymorphic  data. 

The  MIL  calculus  differs  from  the  Aj^calculus  of  [HM95]  in  that  it  does  not  contain  an  explicit 
type  analysis  construct  such  as  typerec  or  typecase.  This  does  not  mean  however  that  the  idea 
of  intensional  type  analysis  has  been  abandoned:  rather,  the  type  analysis  has  been  hidden  inside 
the  primitives  which  need  to  use  it.  For  example  the  constructor  argument  to  the  polymorphic 
subscript  operator  sub[c](e,e)  is  actually  used  at  runtime  to  determine  the  appropriate  stride. 
This  polymorphic  subscript  in  the  language  without  a  typecase  can  be  thought  of  as  a  derived 
form  in  an  underlying  language  with  typecase:  that  is,  subscript  is  a  polymorphic  function  which 
internally  uses  typecase  to  choose  the  appropriate  monomorphic  subscript  operator. 
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2.3.2  Floating  point  numbers 

TILT  deals  with  floating  point  numbers  by  using  two  different  types,  Boxedfloat  and  Float  corre¬ 
sponding  to  the  types  of  boxed  and  unboxed  floats,  with  appropriate  term  level  coercions  between 
them.  This  allows  the  optimizer  to  deal  directly  with  data  representation  optimizations,  even  at 
the  relatively  high  level  of  the  MIL.  To  prevent  unboxed  floats  from  being  passed  to  polymorphic 
functions  or  to  polymorphic  primitives  (such  as  pair  injections  and  projections),  the  Float  type  is 
restricted  to  the  type  level.  The  predicativity  restriction  therefore  enforces  the  uniform  represen¬ 
tation  of  polymorphic  arguments.  In  non-polymorphic  argument  positions  on  the  other  hand,  the 
compiler  is  free  to  use  the  unboxed  floating  point  type.  This  is  more  efficient  because  it  avoids 
repeatedly  boxing  and  unboxing  arguments,  and  also  since  it  allows  floating  point  arguments  to  be 
passed  in  floating  point  registers. 

One  obvious  problem  with  this  is  that  the  type  of  arrays  of  unboxed  floats  cannot  be  constructed 
in  this  system,  since  the  argument  to  the  array  constructor  must  be  a  constructor  (not  a  type). 
This  would  seem  to  mean  that  we  are  unable  to  implement  flattened  float  arrays.  However,  by  using 
type  analysis  in  the  array  constructor  as  well  as  the  subscript  operator,  we  can  avoid  at  least  some 
of  the  difficulty.  There  is  nothing  that  prevents  the  Boxedfloat  array  type  from  being  implemented 
using  unboxed  floats,  even  though  the  Boxedfloat  type  itself  may  be  boxed. 

The  downside  of  this  is  that  the  subscript  operation  will  therefore  actually  have  to  do  a  runtime 
typecase  in  order  to  determine  the  stride  of  an  array  of  unknown  types.  Moreover,  even  when 
the  type  is  known,  the  subscript  operation  will  be  forced  to  rebox  the  float  before  returning  it, 
since  subscripting  into  an  array  of  boxed  floats  returns  a  value  of  type  Boxedfloat.  To  avoid  this 
problem,  we  provide  a  specialized  floating  point  subscript  fsub(e,z)  which  is  well  typed  only  when 
its  argument  is  a  Boxedfloat  array ,  but  which  returns  a  value  of  type  Float .  This  primitive  avoids 
the  problems  with  using  the  standard  polymorphic  subscript  in  cases  where  the  element  type  is 
statically  known  to  be  Boxedfloat ,  since  it  need  not  dispatch  on  its  constructor  argument,  and  since 
it  does  not  need  to  rebox  its  return  value. 


2.4  Algorithmic  typechecking 

In  addition  to  using  types  for  runtime  optimization,  TILT  was  also  designed  with  the  idea  that  the 
type  annotations  can  provide  a  degree  of  self-checking  within  the  compiler:  just  as  a  programmer 
profits  from  the  degree  of  error  checking  imposed  by  the  typechecker,  so  should  a  compiler.  With 
this  in  mind,  a  good  deal  of  work  went  into  designing  efficient  algorithms  for  typechecking  the  MIL. 

Modulo  the  constructor  equivalence  algorithm  which  is  treated  separately  in  [SH99],  the  com¬ 
plete  typechecking  algorithm  for  the  MIL  is  presented  in  appendix  A. 2.  The  algorithm  is  presented 
as  an  alternative  set  of  typing  rules  which  are  intended  to  express  the  structure  of  the  algorithm:  in 
the  few  cases  where  more  than  one  rule  might  apply  the  result  of  a  single  common  premise  indicates 
which  rule  is  applicable.  The  algorithmic  judgements  are  listed  in  figure  5.  The  most  noticeable 
presentational  change  is  that  the  constructor  and  term  well-formedness  rules  have  been  split  into 
synthesis  and  analysis  rules.  For  the  term  level,  the  intension  is  that  the  synthesis  algorithm  cor¬ 
responds  to  synthesizing  a  type  for  a  term:  given  a  well-typed  term,  the  algorithm  will  return 
its  type.  In  the  case  of  the  analysis  algorithm  the  type  is  an  additional  argument:  the  algorithm 
checks  that  the  term  argument  is  well  formed  at  that  type.  The  constructor  level  algorithms  work 
in  the  same  manner,  with  the  additional  constraint  that  the  kind  returned  by  the  kind  synthesis 
algorithm  is  principal. 


7 


A  K 

Well-formed  kinds. 

A  K\  <  K2 

Subkinding. 

A  |=  C  K 

Kind  analysis 

A  |=  C  ft  K 

Kind  synthesis 

A  t-  Cj  =  C2  ::  n 

Constructor  equivalence. 

A  (=  r 

Well  formed  type 

A  (=  e  JJ,  r 

Type  analysis 

A  | =  e  ft  r 

Type  synthesis 

A  (=  c  cf 

Constructor  weak  head  normal  form 

Figure  5:  MIL  algorithmic  judgements 


2.4.1  Selfification 

Unlike  the  declarative  system,  the  algorithmic  MIL  has  no  extensionality  rules  and  no  explicit 
self  rule.  Instead,  the  base-cases  for  the  kind  synthesis  algorithm  include  implicit  applications  of 
the  self-rule.  For  the  most  part  this  is  very  straightforward:  for  example,  the  rule  for  the  Int 
constructor. 

_  Int 

A  |=  Int  Sj{Int) 

In  the  variable  rule  however,  it  is  not  necessarily  possible  to  apply  the  self  rule  directly,  since  the 
variable  may  be  bound  at  a  higher  kind.  For  variables,  it  is  necessary  to  inline  implicit  applications 
of  the  extensionality  rules  as  well.  This  is  done  in  the  form  of  an  auxilliary  judgement  called 
selfification:  |=  c  ::  k  ==  k'. 

| =  q  ::  k  =  k' 

_  Variable 

A  [a  ::  k]  f=  a  ft  Kf 

Selfification  takes  a  constructor  and  a  kind  and  replaces  the  abstract  components  of  the  kind 
with  singletons  containing  projections  from  and  applications  of  the  constructor.  So  for  example, 
|=  a  ::  E(/3  ::  T).T  =  E (f3  ::  St{ Ki  &))-St{x2  <*).  The  resulting  kind  is  therefore  principal  for  the 
variable  in  question. 

It  is  interesting  to  note  here  that  there  are  some  apparently  arbitrary  choices  to  be  made  in 
the  manner  in  which  selfification  is  done  that  are  nonetheless  significant  from  an  implementation 
standpoint.  In  particular,  the  singleton  rule  could  be  implemented  in  either  of  two  ways. 

_  Singleton  1 

\=  c  ::  Sr{d)  =  St{c) 

_  Singleton  2 

(=C::5T(rf)  =  5T(rf) 

From  a  theoretical  standpoint,  either  choice  gives  a  correct  and  equivalent  kind.  From  an  imple¬ 
mentation  standpoint  however,  the  first  choice  which  replaces  the  contents  of  singletons  tends  to 
yield  smaller  kinds.  The  reason  for  this  is  straightforward:  since  selfification  always  starts  with 
a  variable  as  the  constructor  argument,  the  new  singletons  created  via  selfification  with  the  re¬ 
placement  strategy  always  contain  only  paths  which  are  relatively  quite  small.  In  practice,  the 
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pre-existing  contents  of  the  singletons  are  often  quite  large,  and  are  almost  never  smaller  than  a 
projection  from  a  variable. 

The  rule  for  the  dependent  pair  kind  presents  a  related  choice.  It  is  equally  possible  to  retain 
or  eliminate  occurrences  of  the  dependent  variable  in  the  second  kind,  since  the  constructor  gives 
us  a  definition  for  this  variable. 

|=  c.l  ::  K\  =  |=  c.2  ::  {c.l/a}«:2  =  nf2 

_  Sigma 

(=  c  ::  E (a  ::  ^i).k2  =  E(a  ::  Kj).^ 

By  choosing  to  substitute  for  the  free  occurrences  of  the  variable,  we  ensure  that  selfification  never 
generates  dependent  pair  kinds.  This  property  extends  naturally  through  the  rest  of  the  kind 
synthesis  algorithm:  it  is  possible  never  to  generate  dependent  pair  kinds  as  the  result  of  kind 
synthesis.  This  means  that  the  constructor  projection  rule 

A  \=  c  ft  E (a  ::  «i).k2 

_  Second  projection 

A  |=  7r2cfr  {7r1c/a}K2 

need  not  perform  substitution.  Eliminating  this  substitution  yields  significant  efficiency  gains.  This 
can  be  further  improved  by  noticing  that  a  side  effect  of  using  the  replacement  strategy  for  the 
singleton  case  is  that  the  only  place  that  the  dependent  variable  can  occur  is  in  the  argument 
decoration  of  function  kinds.  Therefore,  the  notion  of  substitution  can  be  specialized  further  to 
avoid  the  unnecessary  traversal  of  the  rest  of  the  kind. 

2.5  Termination  Proofs 

In  this  section,  we  show  the  decidability  of  the  typechecking  algorithm  for  the  MIL  calculus  mod¬ 
ulo  constructor  equivalence.  The  decidability  of  the  constructor  equivalence  algorithm  is  proved 
separately  for  the  A<ss  calculus  in  [SH99].  This  result  extends  trivially  to  the  full  MIL  language. 
Note  that  the  decidability  of  the  formal  system  corresponds  to  termination  of  the  algorithm. 

In  section  2.5.1  the  proof  of  the  decidability  of  sub-kinding  is  given,  followed  in  section  2.5.2 
by  the  proof  of  decidability  of  the  well-formed  kind,  kind  analysis,  and  kind  synthesis  judgements. 
All  of  the  proofs  follow  essentially  the  same  form: 

1.  Define  a  size  metric  mapping  kinds  and  constructors  into  the  natural  numbers  (basically 
textual  size) 

2.  Extend  the  metric  to  derivations 

3.  Show  that  the  judgements  only  permit  derivations  which  only  use  smaller  sub-derivations  as 
hypotheses. 

4.  Observe  that  an  infinite  derivation  contradicts  the  well-foundedness  of  the  natural  numbers 

2.5.1  Termination  of  sub-kinding. 

Consider  the  relation  -<  on  sub-kinding  derivations  J  defined  as  follows:  J\  -<  J2  iff  Ji  is  an 
immediate  sub-derivation  of  J2.  It  suffices  to  show  that  the  -<  relation  is  well-founded,  since  if 
there  are  no  infinite  descending  chains  in  the  relation,  then  clearly  there  are  no  infinite  derivations 
(notice  that  all  rules  have  a  finite  number  of  hypotheses).  To  show  that  this  is  the  case,  we 


9 


exhibit  a  mapping  SZ  which  maps  derivations  to  natural  numbers,  and  show  that  this  map  is  order 
preserving.  For  notational  simplicity,  we  write  SZ( A  f=  kx  <  k2)  for  SZ(J)  where  J  is  a  derivation 
the  conclusion  of  which  is  A  (=  nx  <  k2. 

Definition  1 

SZ{ A  |=  K\  <  k2)  =  $2(ki)  +  S2(k2),  where 

1  if  k  =  T 

1  if  k  =  St{c) 

sz(ki)  +  $z(k2)  if  k  =  E(a  ::  Ki).k2 

S2(ki)  +  5z(k2)  if  k  =  n(a  ::  Ki).k2 

It  is  fairly  easy  to  see  that  5Z  is  a  function  (lemma  1).  This  establishes  that  SZ  serves  as  a 
metric  mapping  derivations  into  the  natural  numbers.  A  less  obvious  result  is  that  SZ  preserves 
the  ordering  ■<  -  that  is,  that  the  immediate  sub-derivations  are  always  smaller  according  to  the 
metric  SZ  (lemma  2).  Given  this  lemma,  the  main  result  (theorem  1)  follows  almost  immediately. 

Lemma  1 

SZ  is  a  function. 

Proof.  It  is  easy  to  see  that  VK3!n  s.t.  sz(k)  =  n  by  induction  over  the  structure  of  k.  The  lemma 
follows  immediately.  ■ 

Lemma  2 

SZ  is  order  preserving.  That  is, 

JX<J2=>  SZ(Ji)  <  SZ(J2) 

Proof.  The  proof  proceeds  by  cases  on  the  last  rule  used  in  J2.  See  appendix  A. 3.1  for  details.  ■ 

Theorem  1 

The  algorithm  for  checking  subkinding  always  terminates.  That  is,  the  algorithmic  rules  for  sub- 
kinding  do  not  permit  any  infinite  sequences  of  rule  applications. 

Proof.  By  the  previous  lemmas,  every  derivation  has  as  immediate  hypotheses  only  sub¬ 
derivations  that  are  strictly  smaller  according  to  a  well-founded  ordering.  Therefore,  there  can  be 
no  derivations  of  infinite  depth,  since  such  a  derivation  would  correspond  to  an  infinite  descending 
chain  in  the  well-founded  ordering.  ■ 

2.5.2  Termination  of  the  well-formed  kind,  kind  analysis,  and  kind  synthesis  algo¬ 
rithms 

The  proof  of  decidability  of  the  well-formed  kind,  kind  analysis  and  kind  synthesis  algorithms 
proceeds  in  much  the  same  fashion  as  above.  The  only  significant  difference  is  that  the  measure 
function  for  derivations  maps  into  lexicographically  ordered  pairs  of  natural  numbers.  This  arises 
because  of  the  form  of  the  kind  analysis  judgement,  and  is  mostly  a  technicality:  it  is  easy  to  see 
that  all  uses  of  the  single  kind  analysis  rule  could  be  inlined  into  the  other  judgements  allowing  the 
proof  to  proceed  as  before. 

We  start  by  defining  measure  functions  which  map  derivations  to  pairs  of  natural  numbers 
ordered  lexicographically  below.  These  functions  are  defined  as  before  in  terms  of  inductively 
defined  functions  sz*()  and  S2C(),  which  act  as  measures  on  kinds  and  constructors,  respectively. 
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Definition  2 


SZk(k)  = 


szc(c)  = 


SZ{J )  = 


1 

szc(c)  +  1 

S2«(ki) +  SZk(k2 ) 
+  SZk(k2) 


if  k  =  T 

if  k  =  St(c ) 

if  k  =  £(a  ::  k\).k2 

if  k  =  n(a  ::  k\).k2 


1 

szc{c  i)  +  szc(c2) 
sze(ci)  +  szc(c2) 
szc{c')  +  1 
szc(c')  +  szk(k ) 
S2c(ci)  +S2c(c2) 
szc{ci)  +  szc{c2) 
szc{c')  +  1 
szc(ci)  +szc(c2 ) 


if  c—  a,  Int,  Boxedfloat 

ifc  =  fj,(ot,P).(chc2) 

if  c  =  Ci  x  c2,  ci  c2,  ci  +  c2 

if  c  =  cf  array 

if  c  =  Xa::nxf 

if  c  =  ci  c2 

if  c  =<  ci,c2  > 

if  c  =  c'.l,  c'.2 

if  c  =  let  a  =  Ci  in  c2  end 


(s2tk(k),0)  if  the  conclusion  is  A  |=  k 

(szc(c),  1)  if  the  conclusion  is  A  f=  c  Jj-  k 

(5^c(c),  0)  if  the  conclusion  is  A  [=  c  ft  k 


The  proof  then  proceeds  almost  exactly  as  in  the  sub-kinding  case,  except  that  there  is  an 
additional  lemma  observing  that  the  selfification  judgement  used  by  the  kind  synthesis  algorithm 
is  also  decidable. 

Lemma  3 

SZ  is  a  function. 

Proof.  It  suffices  to  show  that  szc(),  and  szK()  are  well-defined.  This  follows  by  induction  over 
the  structure  of  k  and  c.  ■ 

Lemma  4 

The  selfification  judgement  f=  c  ::  K\  =  k2  is  decidable. 

Proof.  Follows  by  induction  over  the  structure  of  k.  ■ 

Lemma  5 

SZ  is  order  preserving.  That  is, 

JX^J2^  SZ(Ji)  <  SZ(J2) 
where  <  is  the  lexicographic  ordering  on  N  x  N. 

Proof.  The  proof  proceeds  by  cases  on  the  last  rule  used  in  J2.  See  appendix  A. 3. 2  for  details.  ■ 

Theorem  2 

The  kind  synthesis,  kind  analysis,  and  kind  well-formedness  judgements  are  decidable. 

Proof.  By  lemma  5,  any  infinite  sequence  of  rule  applications  corresponds  to  an  infinite 
descending  chain  of  pairs  of  natural  numbers  ordered  lexicographically,  which  contradicts  the  well- 
foundedness  of  (N  x  N,  <).  ■ 
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2.6  Efficiency  concerns  with  the  MIL 


In  the  previous  sections  we  define  a  language  sufficiently  expressive  for  our  purposes  and  give 
algorithms  for  checking  the  well-formedness  of  terms  in  this  language.  This  language  is  very  close 
to  the  original  MIL  calculus  that  was  first  used  in  the  TILT  implementation.  While  sufficient  from 
a  theoretical  perspective,  this  turns  out  to  suffer  from  some  practical  deficiencies. 

An  early  challenge  in  the  TILT  implementation  was  to  keep  the  size  of  the  compiler  intermediate 
forms  manageably  small.  In  some  cases  relatively  small  programs  increased  in  size  dramatically 
when  translated  into  the  MIL,  and  larger  programs  became  simply  unmanageable.  Surprisingly, 
measurements  suggested  that  a  good  deal  of  the  program  size  was  due  to  kinds. 

One  of  the  major  reasons  for  this  becomes  apparent  upon  closer  inspection  of  the  MIL  typing 
rules.  Because  singleton  kinds  are  restricted  to  contain  only  constructors  of  kind  T,  constructors  of 
higher  kind  end  up  being  duplicated  in  their  principal  kinds.  For  example,  if  c  is  a  large  constructor 
of  kind  T  x  T  then  principal  kind  of  c  is  Sj{ tti  c)  X  Sj( n2  c):  the  kind  is  more  than  twice  as  large 
as  the  constructor  it  classifies.  The  duplication  of  constructors  in  kinds  is  quite  pernicious:  since 
structures  and  functors  turn  into  constructor  records  and  functions,  kinds  may  contain  many  copies 
of  entire  structures.  This  becomes  especially  bad  in  the  case  of  nested  structures,  a  common  ML 
programming  idiom. 


2.6.1  Singletons  at  higher  kinds 


S(c::T) 
S(c::ST(c')) 
S(c::Tl(a  ::  Ki).k2 ) 
5(c::E(a  ::  Ki).«2) 


St(c) 

St(c) 

If(a  ::  Ki).S(ca::n2) 

E(a  ::  S( 7Ti  c::ki)).S(7t2c::k2) 


Figure  6:  Definability  of  singletons  at  higher  kind 

An  obvious  solution  to  the  constructor  duplication  problem  is  to  permit  the  use  of  singletons  at 
higher  kind.  This  is  not  at  all  difficult  so  long  as  the  singletons  are  labeled  with  the  kind  of  their 
contents:  in  fact,  as  figure  6  shows,  this  is  definable  in  the  original  calculus.  This  allows  for  kinds 
of  the  form  5j( tt\  c )  X  Sj{ ^2  c)  to  be  replaced  with  an  equivalent  kind  of  the  form  S(c::T  X  T), 
which  contains  only  one  copy  of  the  classified  constructor. 

In  practice  however,  this  solution  is  not  sufficient:  kinds  still  account  for  too  much  of  the  space 
used  by  the  intermediate  forms.  In  this  system,  the  decorations  on  the  singletons  themselves  now 
occupy  a  significant  amount  of  the  space  saved  -  the  kinds  used  are  generally  smaller,  but  there 
are  more  of  them.  Moreover,  it  is  hard  to  systematically  avoid  the  creation  of  kinds  of  the  form 
S(c::S(c::T)):  a  perfectly  legitimate  kind,  but  not  desirable  from  an  efficiency  standpoint. 

As  a  result  of  these  observations,  it  became  clear  that  what  was  needed  was  a  system  containing 
unlabelled  singletons  at  higher  kind:  S(c)  instead  of  S(c::n).  In  such  a  system,  the  principal  kind 
of  a  constructor  c  is  always  S(c).  This  kind  is  both  small,  and  fast  to  synthesize,  but  does  not 
provide  any  useful  structural  information.  An  attempt  to  use  this  kind  (for  example,  to  determine 
if  a  projection  from  a  variable  of  this  kind  is  well-formed)  requires  additional  work.  The  system 
with  unlabelled  singletons  introduces  a  significant  measure  of  type  reconstruction  into  the  language 
in  addition  to  that  already  introduced  by  the  decision  to  elide  classifiers  on  let  bindings.  (In  fact, 
if  we  view  the  binding  let  a  ::  k  =  ci'mc2end  as  syntactic  sugar  for  \a::S  (ci::k)  .c2  [SH99],  then 
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it  becomes  clear  that  eliding  the  classifier  on  let  bindings  is  merely  a  special  usage  of  unlabelled 
singletons:  i.e.  let  a  =  cjinc2end  corresponds  to  Aa::5(ci).C2.) 

Because  of  this  additional  burden  of  type  reconstruction,  it  is  not  immediately  clear  that  the 
language  with  unlabelled  singletons  is  decidable:  unlike  labelled  singletons,  there  is  no  simple 
inductive  definition  that  tells  what  the  corresponding  simple  singleton  kind  is.  The  next  section 
defines  a  language  with  unlabelled  singletons,  presents  an  algorithm  for  typechecking,  and  proves 
its  decidability. 

3  NIL  (Extended  MIL) 

The  relatively  simple  core  calculus  described  above  is  sufficient  from  the  standpoint  of  serving  as  a 
target  language  for  the  elaboration  phase.  However,  from  the  standpoint  of  efficient  implementation, 
it  is  somewhat  deficient.  This  section  describes  the  extension  of  the  MIL  language  to  permit 
unlabelled  singletons  at  higher  kinds.  For  clarity,  we  use  the  term  NIL  to  describe  this  extended 
calculus. 

3.1  Syntax 


k  ::=  S{c)\T\ST{c)\E{a::k).k\Il(a::k).k 

c  ::=  ...  |  A a:\k_.c 

t  ::=  T(c)  |  (a  ::  k,  x  :  t)  t  \  Float 
|  t  x  t  |  let  a  =  cin  t  end 

p  ::=  a-  |  p.  1  |  p. 2  |  pc 

e  ::=  x  |  let  x  =  e  in  e  end  |  let  a  =  c  in  e  end 
|  rec  /  =  X(a::k,  x  :  r)  :  r.e 

I  e[cle  |<  e,  e  >|  e.l  |  e.2  |  n  \  r  \  boxfloat(e)  |  unboxfloat(e) 
|  inlCiCe  |  inrCiCe  |  caseT  eof  {inl(x)  =*>  e,  inr(z)  =>  e} 

|  rollc(e)  |  unroll(e)  |  proj4(e) 

|  arrayc(e,  e)  |  sub[c](e,e)  |  fsub(e,e) 

A  ::=  •  |  A[a;  :  r]  |  A[a::K] 


Figure  7:  NIL  Syntax 


The  syntax  for  the  NIL  language  is  given  in  figure  7:  the  only  change  from  the  MIL  is  the  addition 
of  the  unlabelled  singleton,  5(c).  For  the  sake  of  clarity,  we  write  kinds  in  this  extended  calculus 
as  k  instead  of  k,  which  we  reserve  for  the  core  calculus. 
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There  are  two  points  of  importance  to  the  extended  system  that  are  already  evident  in  the 
syntax.  The  first  is  that  the  addition  of  unlabelled  singletons  does  not  replace  the  core  singleton 
at  kind  T:  the  original  singleton  form  is  still  present  in  syntax.  The  second  point  is  that  typing 
contexts  are  restricted  to  contain  kinds  k  from  the  core  calculus  only:  there  are  no  unlabelled 
singletons  allowed  in  the  context.  These  two  facts  are  the  key  to  making  the  algorithm  terminate. 


3.2  Algorithmic  judgments 


New  judgements 

A  |=  k\n  Kind  standardization 

A  f=  c\c'  Constructor  standardization 


New  versions  of  old  judgements 

A  |=  k  Well-formed  kinds. 

A  |=  c  Ij.  k  Kind  analysis 

A  (=  c  ft  k  Principal  kind  synthesis 

A  |=  r  Well  formed  type 

A  |=  e  If  t  Type  analysis 

A  (=  e  ft  r  Type  synthesis 


Unchanged 
A  ok 

A  (=  ^  *2 

A  b  Ci  =  C2  ::  k 


Well-formed  context 
Subkinding. 

Constructor  equivalence. 


Figure  8:  Nil  declarative  judgements 


The  judgements  used  to  define  the  NIL  typechecking  algorithm  are  listed  in  figure  8,  and  are 
described  in  full  in  appendix  B.l.  The  major  change  is  the  addition  of  two  new  judgements: 
kind  standardization  and  constructor  standardization.  We  call  a  kind  standard  if  it  contains  no 
occurrences  of  unlabelled  singletons.  A  constructor  is  standard  if  it  contains  only  standard  kinds. 
Notice  that  every  standard  kind  is  a  MIL  kind.  These  new  judgements  implement  the  process  of 
putting  a  kind  or  constructor  into  standard  form. 

The  kind  standardization  algorithm  traverses  compositionally  over  the  structure  of  kinds  until  it 
reaches  a  singleton  type.  In  the  case  that  the  singleton  is  not  standard  it  is  necessary  to  reconstruct 
the  principal  standard  kind  by  calling  the  kind  synthesis  algorithm  on  the  constructor. 

A  |=  c  ff  K 

_  Singleton  Any 

A  (=  S(c)\k 

If  the  singleton  is  already  standard,  all  that  remains  to  be  done  is  to  standardize  the  constructor. 
A  (=  c\c' 

_  Singleton  Type 

A  f=  St{c)\St{c') 

The  labelled  singleton  is  important  here:  it  provides  a  way  of  marking  singletons  which  do  not 
require  further  type  reconstruction  efforts. 
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Notice  that  the  kind  synthesis  algorithm  is  designed  to  synthesize  standard  kinds  for  non¬ 
standard  constructors.  This  mixing  of  the  two  systems  is  important  for  a  number  of  reasons,  but 
here  we  see  how  it  comes  into  play  during  kind  standardization:  if  kind  synthesis  returned  non¬ 
standard  kinds  we  would  not  have  made  progress  here.  This  intertwining  of  the  two  systems  is 
essential  to  the  algorithm. 

The  constructor  standardization  algorithm  is  straightforward:  it  simply  traverses  the  construc¬ 
tor,  standardizing  any  kinds  that  it  finds. 

A  f=  k\n  A[a::n]  |=  c\cf 
_  Lambda 

A  f=  \a::k.c\\a::K.cf 

It  is  also  possible  to  generalize  the  system  slightly  by  using  an  intermediate  form  wherein  non¬ 
standard  constructors  are  allowed  inside  of  standard  singletons  so  that  constructor  standardization 
is  no  longer  necessary.  This  is  a  relatively  straightforward  extension,  and  for  the  sake  of  brevity  we 
do  not  elaborate  on  it  here. 

The  kind  synthesis  algorithm  now  proceeds  much  as  before,  but  with  additional  calls  to  the  kind 
standardization  algorithm  where  necessary  to  preserve  the  property  that  all  kinds  in  the  context 
are  standard. 

A  (=  k  A  |=  k\n 

A[a::«]  f=  c  ft  a  £  Dom(A) 

_ 1 _  Lambda 

A  A a::k.c  ft  U(a  ::  *;).*/ 

In  the  variable  rule  we  can  see  the  importance  of  this  property. 

\=  a  ::  k  ==  k9 

_  Variable 

A[q;::k]  |=  a  ft  nf 

Because  the  contents  of  the  context  are  already  standard,  it  is  not  necessary  to  call  back  to  the 
kind-standardization  algorithm  here.  Much  as  with  labelled  singletons  in  the  kind  standardization 
algorithm,  this  gives  the  algorithm  a  place  to  stop. 

The  fact  that  the  kind  synthesis  algorithm  returns  standard  kinds  is  also  important  internally 
to  the  algorithm  in  cases  where  it  must  inspect  kinds.  In  the  projection  rule,  the  fact  that  the  kind 
returned  is  standard  means  that  the  only  possible  form  for  the  kind  of  the  constructor  is  that  of  a 
pair,  and  hence  no  further  work  need  be  done  to  determine  if  the  projection  is  well  formed. 

A  f=  c  ft  E(c*  ::  ki).k2 
_  First  projection 

A  1=  TTi  C  fr  Ki 

The  rest  of  the  judgements  change  from  the  MIL  only  in  minor  ways:  either  additional  cases  to 
handle  the  new  construct,  or  additional  calls  to  kind  standardization  where  needed.  Interestingly, 
the  subkinding  and  constructor  equivalence  algorithms  carry  over  intact  to  the  new  system:  it 
naturally  falls  out  that  the  only  calls  to  these  algorithms  are  made  with  standardized  arguments. 

3.3  Soundness  and  Completeness 

It  is  important  for  the  purposes  of  the  compiler  that  the  extended  system  be  complete  with  respect 
to  the  core  system:  that  is,  that  all  programs  which  could  be  typechecked  in  the  core  system  can 


still  be  typechecked  in  the  extended  system.  This  property  holds,  as  stated  in  theorem  3.  The 
proof  of  this  theorem  follows  almost  trivially,  since  the  NIL  is  a  syntactic  superset  of  the  MIL  and 
since  the  well-formedness  judgements  of  the  NIL  closely  parallel  those  of  the  MIL.  For  clarity  in 

the  statement  of  the  theorems,  we  write  the  NIL  well-formedness  judgements  with  a  superscripted 
+ 

turnstyle,  as  such:  |=. 

Theorem  3  (Completeness) 

The  extended  system  is  complete  with  respect  to  the  core  system. 

+ 

1.  if  A  ok  a nd  A  |=  k,  then  A  |=  k. 

+ 

2.  if  A  ok  and  A  |=  c  ff  k,  then  A  |=  c  k. 

Proof.  First  observe  that  every  MIL  kind  is  a  syntactically  valid  standard  NIL  kind.  Then 
observe  that  the  kind  standardization  algorithm  is  the  identity  on  standard  kinds.  The  proof  then 
follows  easily  by  induction  over  the  structure  of  typing  derivations.  ■ 

While  completeness  is  the  most  important  property,  it  is  desirable  that  the  system  be  sound  with 
respect  to  the  core  system  as  well:  that  is,  that  it  does  not  allow  us  to  typecheck  more  programs 
than  before.  Theorem  4  states  this  property.  The  proof  of  this  theorem  is  less  obvious,  but  not 
significantly  more  difficult. 

Theorem  4  (Soundness) 

The  extended  system  is  sound  with  respect  to  the  core  system. 

+ 

1.  if  A  ok  and  A  | =  k  then  there  exists  a  k  such  that  A  |=  k\n  and  A  (=  n 

+ 

2.  if  A  ok  and  A  |=  c  ft  k  then  there  exists  a  cf  such  that  A  \=  c\cf  and  A  (=  c'  ft  k 

Proof.  By  induction  over  the  structure  of  typing  derivations  ■ 

These  two  basic  theorems  show  that  from  a  theoretical  standpoint  the  NIL  is  a  sensible  extension 
of  the  MIL.  The  next  section  will  show  that  in  addition  to  being  sound  and  complete  with  respect 
to  the  core  system,  the  extended  system  is  also  decidable.  This  is  the  last  and  in  some  ways  the 
most  important  property  that  the  extended  system  must  hold. 

3.4  Termination  Proofs 

The  proof  of  decidability  of  the  extended  system  proceeds  much  as  with  the  core  system,  defining 
measure  functions  which  map  derivations  to  pairs  of  natural  numbers  ordered  lexicographically  and 


using  these  to  argue  that  the  system  is 

well-founded. 

Definition  3 

r  1 

if  k  =  T 

szc(c)  +  1 

E-, 

It 

szk{k)  =  < 

SZc(c)  +  1 

if  k  =  5(c) 

S%(£i)  +  szk(k2) 

if  k  =  E(q'  ::  k_i).k2 

,  SZki^)  +  SZkih) 

if  k  =  Il(a  ::  k^.k^ 
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szc(c) 


SZ{J) 


'  1 

SZc(Cl)  +  SZc{c2) 

szc(ci)  +  szc(c2) 
szc(d)  +  1 
<  szc(cf)  +  szk(k) 
szc(cx)  +  szc(c2) 
szc{ci)  +  SZc(c2) 

SZc(c ')  +  1 

,  szc{ci)  +  szc(c2) 


if  c  =  a,  Int ,  Boxedfloat 

ifc  =  /i(a,/?).(ci,c2) 

if  c  =  Ci  x  c2,  C!  -»  c2,  Cj  +  c2 

if  c  =  cf  array 

if  c  =  A  a::k.cf 

if  c  =  ci  c2 

if  c  =<  ci,c2  > 

if  c  =  c'.l,  c'.2 

if  c  =  let  a  =  ci  in  c2  end 


(fc) ,  0)  if  the  conclusion  is  A  \=  k\n 

(szc(c),  0)  if  the  conclusion  is  A  f=  c\c 9 

<  (szk(k),  0)  if  the  conclusion  is  A  (=  k 

(szc(c),  1)  if  the  conclusion  is  A  |=  c  k 

k  (szc(c),  0)  if  the  conclusion  is  A  |=  c  k 


As  before,  we  argue  that  the  measure  is  a  well-defined  function.  Note  that  the  selfification  result 
of  lemma  4  still  holds,  since  selfification  is  only  performed  on  standard  kinds. 

Lemma  6 

SZ  is  a  function. 

Proof.  It  suffices  to  show  that  szcQ,  and  s%()  are  well-defined.  This  follows  by  induction  over 
the  structure  of  k  and  c.  ■ 

Lemma  7 

SZ  is  order  preserving .  That  is, 

Ji<J2 =»  SZ(JX)  <  SZ{J2) 

where  <  is  the  lexicographic  ordering  on  N  X  N. 

Proof.  The  proof  proceeds  by  cases  on  the  last  rule  used  in  J2.  See  appendix  B.2.1  for  details.  ■ 
The  main  result  then  follows  easily  as  before. 

Theorem  5 

The  kind  standardization,  constructor  standardization,  kind  synthesis,  kind  analysis,  and  kind 
well-formedness  judgements  are  decidable. 

Proof.  By  lemma  7,  any  infinite  sequence  of  rule  applications  corresponds  to  an  infinite 
descending  chain  of  pairs  of  natural  numbers  ordered  lexicographically,  which  contradicts  the  well- 
foundedness  of  (N  x  N,  <).  ■ 


4  Conclusion 

This  paper  presents  a  language  very  close  to  that  actually  used  in  the  internals  of  the  TILT  compiler: 
a  language  whose  design  was  driven  not  by  the  usual  concerns  of  programer  usability,  but  by  the 
new  concern  of  compiler  usability.  This  difference  in  purpose  leads  to  very  different  concerns 
than  those  normally  encountered  by  language  designers.  We  have  discussed  here  some  of  the 
more  important  design  decisions  resulting  from  this  in  the  original  core  calculus,  and  we  have  also 
described  the  extension  of  the  calculus  to  allow  unlabelled  singletons  for  the  purpose  of  providing 
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compact  representations  of  internal  forms.  This  extension  has  been  shown  sound  and  complete, 
and  decidable. 

The  work  described  here  was  a  key  part  of  making  the  TILT  compiler  run  efficiently,  and  well. 
It  is  of  particular  interest  because  it  presents  a  theoretical  approach  to  solving  a  practical  problem. 
This  is  indicative  of  the  overall  design  philosophy  of  the  TILT  project:  that  a  systematic  and 
theoretically  sound  approach  to  practical  problems  provides  significant  engineering  benefits.  The 
use  of  a  new  language  construct  (unlabelled  singletons)  to  achieve  an  engineering  goal  (better  space 
efficiency)  is  an  excellent  example  of  how  this  can  work. 
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A  MIL 

A.l  Declarative  judgements 

Well  Formed  Context 

_  Empty 

•  ok 


A  ok  A  I-  k  a  £  Dom(A) 
A[a::«]  ok 


Kind 


A  ok  A  I- r  x  £  Dom(A) 
A[x  :  r]  ok 


Type 


Well  Formed  Kind 


A  ok 

-  Type 

APT 


A  Pcv.T 

_  Singleton 

AbSr(c) 

A  h  K]  A[o::ki]  I-  «2 
_  Pi 

A  h  Il(a  ::  Kj).k 2 

AI-ki  A[a::«i]  h  «2 

_  Sigma 

A  h  E(<*  ::  Ki).«2 


Sub-Kinding 
A  ok 

-  Type 

AhT^T 

A  h  ST(c) 

_  SingletonL 

A  I-  St(c)  <  T 


A  ok 


A  H  k 


A  I-  Ki  <  K2 
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A  \-c  =  d::T 


-  Singletons 

A  1-  ST{c)  <  ST(d) 

A  h  k[  <  A[o-::kj]  b  k2  ^  k'2 

-  Pi 

A  b  n(a  ::  ki).k2  ^  n(a  ::  Kj).k'2 

A  b  ^  A[q::ki]  \~  K2  -<  k'2 

-  Sigma 

A  b  E(a  ::  ki).k2  ■<  E(a  ::  Ki).k2 


Well  formed  constructor 
A  ok 


Variable 


Aba::  A  (a) 


A  ok 


A  b  BoxFloat  ::  T 


BoxFloat 


A  ok 


A  b  Int  ::  T 


Int 


A[a::T][/3::T]  b  Cl  ::  T  A [a::T][0::T]  b  c2::T 

_  Mu 

A  b  fi(ck,  /3).(c\,  c2)  ::  T 


Abcj  ::T  A  b  c2  ::  T 


A  h  Ci  X  C2  : 

::  T 

A  b  ci  ::  T 

A  b  c2  ::  T 

A  b  Ci  — >  c2 

::T 

A  b  ci  ::  T 

A  b  c2  ::  T 

A  b  ci  +  c2 

::  T 

A  b  ci  ::  T 

A  b  c2::T 

A  b  cj  c2  ::  T 
A  b  c  ::  T 

_  Array 

Ah  c  array  ::  T 


Pair 


Arrow 


Sum 


KnownSum 


A  h  c  ::  K 
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A  b  k  A[ct::/c]  b  c  ::  k' 


Lambda 


A  b  A(a  ::  k).c  ::  n(o  : 

:  k).k' 

A  h  ci  ::  U(a  :: 

A  h  C2  ::  «i 

A  b  ci  c2  ::  {c2/a}/C2 

A  h  c\  ::  Kj  A  h  C2  :: 

k2 

Record 

A  b  (cj,  c2)  ::  «i  x  k2 

A  h  c  ::  E(a  ::  ki).K2 

Projl 

A  h  c.l  :: 

A  h  c  ::  £(a  ::  Ki).ft2 

Proj2 

A  b  c.2  ::  {c.l/a}«2 

A  h  ci  ::  AfairKi]  h  C2  ::  ^2 

A  h  let  a  =  Ci  inc2end  ::  {ci/a}^ 

A  b  c::T 

Selfify 

Abe::  Sj(c) 

A  b  c  ::  k  A  b  k  K  k' 

Subkind 

A  b  c  ::  k' 

Abe::  E (a  ::  Ki).«2 

A  b  c.l  ::  k[ 

Abe::  E(cc  ::  k'x).k2 

Abe::  E(a  ::  ki).k2 

A  b  c.2  ::  k2 

App 


Let 


Sigma  Extl 


Sigma  Ext2 


A  h  c  ::  Ki  x  «2 

A  h  c  ::  n(a  ::  Ki).«2  A[a::«x]  b  ca  ::  k'2 
Abe::  11(0' ::  kx).k!2 


Pi  Ext 
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Well-formed  Type 


A  hc::T 

_  Constructor 

A  b  T(c) 


A  b  k  A[o::k]  b  rj  A[o::k]  b  r2 


A  b  (a  ::  k,  ri)  r2 


Arrow 


A  ok 

_  Float 

A  b  Float 


A  b  Tj  A  b  72 

-  Float 

A  b  Tj  X  r2 

A  b  c  ::  A[o::ki]  b  r 

_  Let 

A  b  let  a  —  c  in  r  end 


Well-typed  term 

A  ok 

_  Variable 

Aba::  A(x) 

A  b  ex  :  T\  A  [a:  :  rj]  b  e2  :  r2 

_  LetE 

A  b  let  x  =  e\  in  e2  end  :  r2 


A  b  c  ::  k  A[q’::k]  be  :  t 

_  LetC 

A  b  let  a  =  c  in  e  end  :  let  a  =  c  in  r  end 


A  b  k  A[a::/v]  b  ri  A[q::k]  b  r2 

A[/  :  (a  ::  k,  rj)  -4  r2][o::K][x  :  n]  b  e  :  r2 

A  h  rec  /  =  A(q::k,  x  :  Ti)  :  T2.e  :  (a  ::  k,  rj)  T2 


A  h  e\  :  (a  ::  k,  ti)  72  A  I -  c  ::  k 
A  h  e2  :  {c/a}ri 

A  b  ei[c]e2  :  {c/a}r2 


App 


A  b  e\  :  ri  A  b  e2  :  r2 
-  Pair 

A  b  (ei,e2)  :  ri  x  r2 


A  h  r 


Ah  e  :  r 
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A  he  :  T\  x  r2 


A  b  e.l 

:  t\ 

Abe: 

T\  x  r2 

A  h  e.2 

:  r2 

A  ok 

A  b  r  : 

Float 

A  ok 

Projl 


Proj2 


Float 


Int 


A  b  n  :  T(Int) 

A  he  :  Float 

A  b  boxfloat(e)  :  T (Box Float) 


Box 


Ahe  :  BoxFloat 


A  h  unboxfloat(e)  :  Float 


Unbox 


Abe:  T(c\  +  C2) 

A[x  :  T(ci  +1  c2)]  b  e\  :  r  A[x  :  T(ci  +2  c2)]  b  e2  :  r 
A  b  caseT  e  of  {inl(x)  ei,  inr(x)  =>  e2}  :  r 


Sumswitch 


A  b  ci  ::  T  A  b  c2  ::  T 
Abe:  T(cj) 

A  b  inlC]iC2e  :  T(ci  +  c2) 


A  b  a  ::  T  A  b  c2  ::  T 

Abe:  r(c2) 

_  inr 

A  b  inrCl)C2e  :  T(ci  +  c2) 

A  b  c  ::  T  A  b  c  =  ^(a,/?).(ci,c2).J ::  T 

Abe  :  T({c.l, c.2/a,/9}c,) 

A  b  rollc(e)  :  T(c) 


Abe  :  r  A  b  r  =  T(/i(o',/?).(ci,c2).i) 

_  unroll 

A  b  unroll(e)  :  T({/i(o,/3).(c1,c2).l,//(a,/3).(ci,c2).2/o,/3}c,) 

Ahe  :  r  A  b  r  =  T(c\  +*  c2) 

-  proj 

A  b  projj(e)  :  T(ci) 
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A  h  ei  :  Int  A  I -  c  ::T 
A  h  e2  :  T(c) 

-  array 

A  b  arrayc(ei,  e2)  :  T(c  array ) 

A  h  e\  :  T(c  array)  Ahe2  :  T(Int) 

-  sub 

A  I-  sub[ej](e2,  )  :  T(c) 

A  h  e\  :  T  (Box  FI  oat  array)  A  f-  e2  :  T(Int) 


A  h  fsub(e!,  e2)  :  F/oai 

A. 2  Algorithmic  judgements 

Well  Formed  Kind 

-  Type 

A  |=  T 

A  1=  c  Ij.  T 

_  Singleton 

A  |=  St{c) 

A  |=  «i  A[qt::ki]  |=  k2 
_  Pi 


A  |=  n(a  ::  kj).k2 


fsub 


A  f=  A[ct::«i]  }=  k2 
_  Sigma 

A  (=  S(a  ::  Ki).k2 


Sub-Kinding 

Assume  that  A,  and  k2  are  well-formed.  Check  that  «i  is  a  subkind  of  k2. 

-  Type 

A  1 =T<T 

_  Singleton 

A  |=  Sj{c)  ^  T 

A| =c=d::T 

_  Singletons 

A  |=  ST(c)  <  ST(d) 

A  |=  <  Kj  A  [a  ::  Atj]  (=  k2  <  k'2  a  ^  Dom(A) 

A  |=  n(a  ::  K\).K2  ■<  II(a  :: 

A  (=  Ki  ^  k[  A  [a- ::  k2]  |=  k2  <  k'2  a  &  Dom(A) 

A  f=  S(a  ::  «i).k;2  <  E(a  ::  k\).k'2 


A  |=  K 


A  (=  «1  ■<  k2 
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Selfification 


c  ::  k  =  k' 


Assume  c  and  k  are  well-formed  with  respect  to  some  context.  Return  the  most  precise  kind  of  c. 
Intuitively,  this  is  the  definition  of  a  singleton  at  the  higher  kind. 


Type 


| =  c::T  =  St{c) 

t=  c  ::  Sr{d)  =  St(c ) 
|=  ca  ::  k2  =  «2 


Singleton 


Pi 


| =  c  ::  II(a  ::  Ki).k2  =  II  (a  ::  ki).k'2 

|=  c.l  ::  Ki  =  Kj  (=  c.2  ::  {c.1/c*}k2  =  «2 
|=  c  ::  S(o  ::  «i )./c2  =  S(a  ::  k[).k'2 


Sigma 


Kind  Analysis 


A  C  fl  K 


Assume  A  and  k  are  well  formed.  Check  that  c  is  well  formed  and  can  be  given  kind  k. 
A  |=  c  fl  A  |=  k'  <  k 


Analysis 


A  |=  c  fl  K 


Kind  Synthesis 


A  (=  C  fl'  K 


Assumes  that  A  is  well-formed.  Check  that  c  is  well-kinded,  and  construct  k  s.t.  A  (=  k  and  c  has 
kind  k. 


\=  a  ::  k  =  k' 

A[a  ::  k]  a  fl  k' 


Variable 


A  f=  BoxFloat  fl  SjiBoxFloat ) 
_  Int 


BoxFloat 


A  \=  Int  fl 

A[a::Tp::T]  |=  T  fl  A [a::T]\j3::T]  \=  T  If  a,  (3  $  Dom(A) 

A  \=  n(a,(3).(ci,c2)  fl  5j(^(o;,^)-(ci,c2).1)  x  5T(M(a,/?)-(ci,c2).2) 


Mu 


A  1=  ci  1J-  T  A  |=  c2  fl  T 
A  (=  ci  x  c2  fl  St{c  1  x  c2) 


pair 
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A  |=  d  -U  T  A^c2^T 


<1 

♦— l 

o 

JL 

-t  C2 

fr  St(ci 

-t  C2) 

< 

1=  ci 

1!T 

A  (=  c2 

1!T 

< 

N  ci 

+  c2 

fr  sT(ci  ■ 

+  e2) 

< 

1=  ci 

1!T 

A  1 =  c2 

-1!  T 

<\ 

1=  ci 

+*  c2 

fr  ^(ci 

+’  C2) 

A 

1 =c|ir 

Arrow 


Sum 


KnownSum 


Array 


A  |=  c  array  ff  Sj{c  array ) 

A  |=  k  A  [a  ::  k]  f=  c  ft  k'  a  £  Dom(A) 
A  (=  A a:\K.c  ff  FI(q  ::  k).k; 


Lambda 


A  \=  Ci  ft*  Il(a  ::  k\).k2  A  (=  c2  ^ 
A  (=  ci  c2  ff  {c2/a}K2 


App 


a  i=  ci  fr  ki  a  |=  c2  fr  k2 

_  Record 

A  1=  (ci,c2)  fr  Ki  x  k2 


A  |=  c  ff  S(a  ::  kj).k2 

-  Projl 

a  |=  c.i  ft  «! 

A  |=  c  -ft-  £(<*  ::  «i).k2 

-  Proj2 

A  f=  c.2  f)'  {c.l/a}«2 


A  f=  Ci  ft  Ki  A  [a  ::  «i]  |=  c2  ff  k2  a  ^  Dom(A) 
A  |=  let  a-  =  Ci  inc2end  ff  {ci/q}k2 


Let 


Well-formed  Type 

Assume  A  is  well-formed.  Check  that  r  is  well-formed. 
A  |=  cl!  T 

_  Constructor 

Ab=T(c) 


A  [=  r 
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A  |=  k  a  £  Dom(A) 

A[o::k]  |=  Ti  AjamK;]  |=  r2 

A  |=  (a  ::  k,ti)  -4  r2 


ArrowType 


Float 


A  |=  Float 


A  |=  n  A  |=  r2 
A  |=  T\  x  r2 


PairType 


Af=cf|-/«i  A[q;::ki]  (=  r  a  ^  Dom(A) 
A  |=  let  a  =  c  in  r  end 


Type  Analysis 

Assume  A  and  r  are  well-formed.  Check  that  e  is  well-typed,  and  has  type  r. 


A  (=  e  f| \r'  A|=t'  =  t 
A  |=  e  JJ  t 


Analysis 


A  |=  e  Jj  t 


Type  Synthesis 


A  [=  e  ff  r 


Assume  A  is  well-formed.  Check  that  e  is  well-formed  and  construct  its  type  r,  where  A  |=  r 


Variable 


A[ar  :  r]  |=  x  ft  r 


A  |=  ei  it  ri  A[x  :  ri]  |=  e2  ff  r2  x  Dom(A) 
_  lete 

A  |=  let  x  =  e\  in  e2  end  ff  r2 

Af=cff«  A[a::/c]  f=  e  ff  r  a  £  Dom(A) 
-  letc 

A  |=  let  a  =  cine  end  ff  let  a  =  c  in  r  end 
A  |=  k  A[a::/c]  [=  T\  A[a::«:]  |=  r2 

A[/  :  (a  ::  k,  tj)  -4  t2][o:::k][x  :  ti]  |=  e  1J  r2  /,  x,  a  ^  Dom(A)) 
-  rec 

A  ^  rec /  =  X(a::K,x  :  r2)  :  r2.e  ff  (a  ::  k,  ri)  -4  r2 

A  \=  ei  ff  (a  ::  k,  n)  -4  r2  A  \=  c,+i  JJ  {c  /a}Ki+1  A  |=  e2  JJ-  {cn/an}r1 
A  f=  ei  [c]e2  ff  let  a  =  c  in  r2  end 


A  f=  e2  ff  r  A  f=  r  i-»  T(c\  — >  c2)  A  [=  e2  JJ  T(ci) 
A  \=  eiOe2  ff  T(c2) 


MonoApp 


27 


A  (=  ei  fr  n  A  (=  e2  ff  r2 


A  \=  (ei,e2)  fr  n  x  r2 


pair 


A(=efrr  A  A  rf)  x  r2 
A  (=  e.l  ft  rj 

A  |=  e  fr  r  A  (=  r  rj  x  r2 
A  |=  e.2  fr  r2 


type.projl 


type_proj2 


_  Float 

A  [=  r  fr  Float 


_  int 

A  |=  n  fr  T(Int) 


A  e  If  Float 

A  |=  boxfloat(e)  fr  T(BoxFloat) 


box 


A  |=  e  If  T (Box Float) 
_  unbox 

A  |=  unboxfloat(e)  fr  Float 


A  f=  e  fr  re  A|=Tei->r(fi  +  c2)  A  (=  t 

A[x  :  Cj  +1  c2]  |=  ei  If  r  A[.r  :  Ci  +2  c2]  |=  e2  Jf  r 

A  |=  caseT  e  of  {inl(a:)  =>  ei ,  inr(x)  e2}  fr 


sumswitch 


A  |=  a  Jf  T  A  |=  c2  If  T 

A^T(c->  ini 

A  |=  inlCliC2e  fr  T(ci  +  c2) 

A\=c$T  A  | =  c2  If  T 
A  1=  e  If  T(c2) 

_  inr 

A  \=  inrCliC2e  fr  T(ci  +  c2) 

A|=clfr  A 

A  |=  e  If  T({c.l,  c. 2/a,  /?}c,) 

A  |=  rollc(e)  fr  T(c) 


A  |=  e  fr  r  A  |=th>  T(^/.(a,  /3)  .(cj,  c2).?) 

_ _  unroll 

A  |=  unroll(e)  fr  T({/r(a,/?).(c1,c2).l,^(a,/?).(c1,c2).2/Q,/?}c!) 
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A  |=  e  ft  r  A[=th)  T[c\  +*  c2) 


A  1=  projj(e)  ft  T{a) 

A  |=  ei  JJ-  T(Int)  Af=cftT 

an^j me) _ 

A  |=  arrayc(el5 1^)  ft  T(c  array ) 


proj 


array 


A  e\  ft]r  A  |=  r  1-4  T{c'  array )  A  (=  e2  JJ-  Int 
_  sub 

A  (=  sub[ei](e2,ft)T’(c/) 


A  |=  e\  ft  T(BoxFloat  array)  A  |=  e2  ft  T(Int) 
A  |=  fsub(ei,e2)  ft  Float 


fsub 


Natural  Kind  Extraction 

Assumes  that  A  and  p  are  well-formed.  Returns  the  unselfified  kind  of  p. 

_  Variable 

A[o:::k]  }=  a  k 

A  \=  p-^>  E(a  ::  Ki).K2 

-  Projl 

A  ^  p.  1 

A  |=  p E(a  ::  ki).«2 
_  Proj2 

A  ^  p. 2  {p.1/g}«2 

A  [=  p Il(a  ::  ki).«2 

-  App 

A  | —pc  'N'*  {c/a}K2 


Weak  Head  Beta  Short  Form 

A  (=  ci  <-4  Aa  ::  k.c\  A  {c2/ot}c\  <-4  c 
-  App 

A  f=  Cl  C2  <-4  c 


A[=C4  (ci,  C2)  A  |=  Cl  <^4  ci 
A  c.l *-4  ci 

A(=ch{ci,c2)  a  1=  c2  ^4  c2 
A  |=  c.2  *-4  c2 


Projl 


Proj2 


A  (=  p  K 


A  |=  c  4  c' 
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A  |=  {ci/q}c2  <-»  c 

- - -  Let 

A  |=  let  a  =  ci  in  c2  end  c->  c 

_  Otherwise 

A  (=C4f 


Constructor  Weak  Head  Normal  Form 

Assumes  that  A  and  c  are  well-formed.  Returns  the  head  normal  form  of  c. 


A  |=  c  <->■  p  A  p  St(c')  A  f=  c'  i->-  c" 
A  f=  c  i->-  c" 


Pathequation 


A  |=  C  p  A  1=  p  ^  k  k  /  St{c') 
A  | —  c  p 


Pathnoequation 


A  | =  c—t  c'  c'  not  a  path 
A  | =  ch>  c' 


NonPath 


Type  Weak  Head  Normal  Form 


A  |=  {c/a}r  h4  t' 

A  |=  let  q  =  c  in  r  end  h4  t' 


Let 


A  |=  c  ci  x  c2 
A  b=  T(c)  ^  T{c\)  x  T{c2) 


Con  pair 


A  |=  c  c' 

_  Inclusion 

A  (=  T(c)  r(c') 

_  Otherwise 

A  [=  T  H >  T 


A. 3  Termination  Proofs 
A.3.1  Proof  of  Lemma  2 

To  show:  SZ  is  order  preserving.  That  is,  Jx  ^  J2  =>  SZ(Ji)  <  SZ(J2) 

Proof.  We  proceed  by  cases  on  the  conclusion  of  J2. 

1.  A  (=  T  <  T.  Vacuously  true:  J2  is  minimal,  and  hence  has  nothing  smaller  than  it. 

2.  A  |=  St(c)  2<  T.  Vacuously  true:  J2  is  again  minimal. 


30 


3.  A  |=  St(c )  -<  Sx{d).  The  rule  for  this  judgement  has  no  sub-kinding  derivations,  and  hence 
has  nothing  smaller  than  it.  The  only  subgoal  is  an  equivalence  derivation,  which  has  been 
shown  to  be  decidable  separately  [SH99]. 

4.  A  |=  n(o  ::  kj).k 2  d  n(a  ::  k\).k2.  Suppose  Jj  -<  J2.  From  the  subkinding  rule  for  the  II 

kind,  we  see  that  there  are  two  possibilities  for  the  conclusion  of  J\\ 

(a)  A  |=  k'i  ^  K\ 

SZ(Ji)  =  sz(k[)  +  sz(k  1) 

<  S^(k,1)  +  S2(Ki)  +  Sz(k2)  +  Sz(k2) 

=  SZ{J2) 

(b)  A[a::«i]  (=  n2  <  k2 

SZ{J\)  =  sz{k2)  +  sz(k2) 

<  S2:(k/1)  +  S2(Ki)  +  S2(K2)  +  S2(K2) 

=  SZ{J2) 

5.  A  1=  E(a  ::  ki).k2  <  E(cv  ::  k[).k2.  Suppose  J\  -<  J2.  From  the  subkinding  rule  for  the  E 

kind,  we  see  that  there  are  two  possibilities  for  the  conclusion  of  J\ : 

(a)  A  |=  «i  ^  . 

SZ(Ji)  =  Sz(k[)  +  sz(ki) 

<  +  S2(«i)  +  Sz(k2)  +  S2(K2) 

=  SZ{J2) 

(b)  A[q-::ki]  |=  k2  <  k2. 

SZ(Ji)  =  sz(k'2)  +  sz(k2) 

<  S2(Kj)  +  S2(ki)  +  Sz(k2)  +  52(k2) 

=  SZ{J2) 


A. 3. 2  Proof  of  Lemma  5 

To  show:  SZ  is  order  preserving.  That  is,  J\  -<  J2  =3>  SZ(J\)  <  SZ(J2 )  where  <  is  the  lexicographic 
ordering  on  IV  x  N. 

Proof.  The  proof  proceeds  by  cases  over  the  conclusion  of  J2,  demonstrating  that  each 
immediate  subderivation  is  strictly  smaller  according  to  the  given  metric.  We  ignore  subderivations 
that  correspond  to  judgements  which  are  independently  known  to  be  decidable,  such  as  subkinding 
and  constructor  equivalence.  Technically,  this  may  be  viewed  as  using  the  constant  measure  that 
always  returns  zero  for  these  judgements. 

1.  Well  Formed  Kind  A  |=  k  We  proceed  by  subcases  on  the  form  of  k. 

(a)  T  No  premises. 
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(b)  St(c) 


SZ(A\=cl±T)  =  (azc(c),l) 

<  (S2c(c)  +  1,0) 

=  5Z(AMtW) 

(c)  n(«!  ::  «2). 

i. 

5Z(A|=ki)  =  (s5k(«i),0) 

<  (s2k(Kj)  +  S2k(k2),  0) 

=  SZ(A|=II(a::K1).K2) 

ii. 

5Z(A[a::Kx]  (=  k2)  =  (s2k(k2),0) 

<  (s2«(Ki)  +  S2k(k2),0) 

=  SZ(A  |=  n(o::  k,).k2) 

(d)  E(«i  ::  k2). 

i. 

SZ(Af=Kj)  =  (s2k(ki),0) 

<  (S2«(ki)  +  SZk(k2),0) 

=  SZ(A  |=  E(a  ::  «i).k2) 

ii. 

5Z(A[o::ki]  (=  k2)  =  (szk(k2),0) 

<  (s2«(Kl)  +S2«(K2),0) 

=  5Z(A  (=E(o::k,).k2) 

2.  Kind  Analysis  A  (=  cj|  k. 

5Z(A  f=  cUk')  =  (S2c(c),0) 

<  (s2c(c),l) 

=  5Z(A  |=  c  1J-  k) 

3.  Kind  Synthesis  A  (=  c  ft  k 

Variable  By  lemma  4 
BoxFloat  No  premises 
Int  No  premises 

Mu 

(a) 

SZ(A[a::T,t3::T]\=Cl\lT)  =  (s2c(c,),l) 

<  (s^c(Cl)  +S2C(C2),0) 
(5^c(^r(o', /?).(cj5  c2)),  0) 

=  SZ(A  |=  n{a,P).{ci,c2)  fr  k) 
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where  k  =  St(h(ch,  (3).{cu  c2).l)  x  ST(^{a,/3).(c1,c2). 2). 

(b)  Similar 

Pair 

(a) 

sz(a  (=  Ci  jj.  r)  =  («c(Cl),  i) 

<  («2c(ci)  +  SZc(c2),0) 

=  (S2c(ci  X  C2),0) 

=  5Z(A  |=  Cl  x  c2  fr  St{ci  x  c2)) 

(b)  Similarly  for  the  second  premise. 

Arrow  As  with  the  Pair  case. 

Sum  As  with  the  Pair  case. 

Array 

SZ(A^c\)T)  =  K(c),  1) 

<  (S2c(c)  +  1,0) 

=  (szc(c  array) ,  0) 

=  SZ(A  |=  c  array  ft  Sj(c  array)) 

Lambda 

(a) 

5Z(A  |=  k)  =  (s2«(k),0) 

<  (sz«(k)  +  szc(c),0) 

=  (s2c(Aa::K.c),  0) 

=  SZ( A  |=  A a:\K.c  ft  II(a  ::  k).k') 

(b) 

SZ(A[a  ::  /c]  |=  c  •ft  k1)  —  (s2c(c),0) 

<  (s2«(k)  +  S2c(c),0) 

=  (s2c(Aa::K.c),  0) 

=  SZ(A  |=  Aa::K.c  ft  n(a  ::  k).k') 

App 

(a) 

SZ{ A  |=  ci  fr  II  (cr ::  «i).k2)  =  (s2c(ci),  0) 

<  (s^c(ci) +  «2c(C2),0) 

=  (S2C(C!C2),0) 

=  5Z(A  |=  ci  c2  fl  {c2/c*}k;2) 

(b) 

SZ( A  f=  C2  ft  Ki)  =  (s2c(c2),  1) 

<  (s^c(ci)  +S2c(c2),0) 

=  (S2c(cic2),0) 

=  SZ(A  f=cic2fr{c2/cr}K2) 
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Record 

(a) 


(b) 


Projl 


SZ( A  |=  Cj  it  «i) 


=  (s«c(ci),0) 

<  (s«c(Cl)  +  S2rc(c2),0) 

=  {,szc(<  cuc2  >),0) 

=  SZ( A  (=<  ci,c2  >ff  Ki  x  k2) 


SZ( A  (=  c2  fr  k2) 


=  (^c(c2),0) 

(cl)  +  s*c(c2),  0) 

=  (szc(<  Ci,c2  >),0) 

=  SZ( A  j=<  ci,c2  >ff  Ki  x  k2) 


5Z(A  |=  c  fr  S(a  ::  ki).k2)  =  (szc(c),0) 

<  (szc(c)  +  l,0) 

=  (S2c(c.l),0) 

=  5Z(A  (=  c.l  f)-  «i) 


Proj2  As  with  Projl 
Let 

(a) 

SZ(A  (=  ci  fr  «i)  = 
< 


(b) 


(szc(ci),0) 

{8Zc{Cl)  +  S2c(c2),0) 

(s2'c(let  a  =  C\  in  c2  end),  0) 

SZ( A  |=  let  a  =  ci  in  c2  end  ft  {ci/o}k2) 


SZ(A[o  ::  «i]  |=  c2  ft  k2)  =  (s2c(c2),0) 


<  («2c(Cl)  +  S2c(c2),0) 


=  (s2c(leta  =  c\  inc2end),0) 

=  5Z(A  |=  leto  =  ci  inc2end  fr  {ci/a}«2) 


B  NIL  (Extended  MIL) 

B.l  Algorithmic  judgments 

Kind  Standardization 

-  Type 

A  (=  T\T 


A  (=  k\n 
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A  b  cV 

A  (=  St{c)\St{c') 


Singleton  Type 


A  b  C  ff  K 
A  b  S(c)\k 


Singleton  Any 


A  b  ki\Ki  A[a::«i]  b  &2\k; 2 
A  b  n(a  ::  fcJ.AkNjIJa  ::  ki).k2 


A  b  &i\«i  A[a::«i]  b  £2X^2 
A  b  S(a  ::  ^.l)-^2\^(a  ::  ki)»k2 


Sigma 


Constructor  standardization 


A  b  <V 


All  cases  proceed  compositionally  over  the  structure  of  the  constructors  except  for  the  following 


A  b  A[a::«]  b  c\c/ 
A  b  Ao::fc.c\Aa::K.c' 


Lambda 


A  b  £i\ci  A  b  ci  ff  K 
A[a::«]  b  C2V'2 

A  b  let  a  =  ci  in  c2  end\let  a  =  c[  in  c2  end 


Type  standardization 


a  MV" 


A  |=  c\d 
A  b  T(c)\T(c') 


Constructor 


A  b  t\K  A[a::«]  b  *i\ri 

A[a::K][a;  :  rx]  b  *2X^2 

A  b  (<* ::  h.i x  •  ^i)  — ^  1 2\(°'  ••  Ki  ^i)  — t  T2 


Arrow 


Float 


A  b  Float\Float 


A  b  tiVi  A  b  h\f2 
A  b  h  x  h\r 1  x  r2 


Well  Formed  Kind 

The  Type  and  Singleton  Type  rules  are  as  before. 
A  b  c  JJ.  T 

Singleton  Any 


A  (=  k 


A  |=  5(c) 


A  b  ii  A  b  iA«i 

A[c*::ki]  b  hi 

A  b  n(or ::  h)-hi 

A  bii  A  bii  \«i 

A[o::ki]  b  hi 

Ab  S(a::£i).*2 


Pi 


Sigma 


Sub-Kinding 


A  b  ^1  ^  Hi 


We  do  not  need  to  redefine  subkinding  for  the  extended  NIL  -  all  queries  will  be  restricted  to  core 
syntax. 


Kind  Analysis 


A[=c((k 


Note  that  we  restrict  this  judgement  to  core  kinds.  Assume  A  and  k  are  well  formed.  Check  that 
c  is  well  formed  and  can  be  given  kind  k. 


A  b  c  fr  k'  A  b  ^  ^  ac 

Abeb 


Analysis 


Kind  Synthesis 


A  b  c  ff  k 


Assumes  that  A  is  well-formed.  Check  that  c  is  well-kinded,  and  construct  k  s.t.  A  b  K  and  c  has 
kind  k. 


b  a  ::  k  =  k' 

A  [a  ::  k]  b  O'  ft 


Variable 


A  b  Box  Float  ff  SriBoxFloat) 
_  Int 


BoxFloat 


A  b  Int  ft  Sx{Int) 


A [a::T][(3::T]  b  ca  ft  T  A [a::T][/3::T]  \=c2^T 
A [a::T][0::T]  b  Ci\cJ  A[a::T][/3::T]  \=  c2\c'  a,  b  $  Dom(A) 

A  b  ^(a,/3).(ci,c2)  ft  5r(M(o,/?).(c'1,c,2).l)  x  5j(^(o, /9).(ci,  c2).2) 


V- 
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A|=CiftT  A  | =  c2ftT 

A  [=  ci \ci  A  |=  c2\c'2 


Pair 

A  |=  ci  x  c2  ft*  5t(c/1  x  cf2) 

A  [=  ci  J)  T  A  |=  c2  T 
A  \=  cx\ci  A  (=  c2\c'2  Ar 

A  {=  cx  ->  c2  ft  St  (4  ->  4) 

A|=ci^r  a  |=  c2  ft  r 
A  (=  cx\ci  A  1=  c2\c'2 

A  f=  ci  +  c2  ft  5r(ci  +  c2) 


A  |=  c  ft  T  A  |=  c\c' 

A  (=  c  array  ft  St{c'  array) 


Array 


A  (=  fc  A  |=  k\n 

Afa  ::  k]  1=  c  ft  k'  a  £  Dom(A) 

_ _ _  Lambda, 

A  (=  Aa::fc.cft  Il(a  ::  k).k' 


A  (=  ci  f|-  n(o  ::  ki).k2  A  |=  c2  JJ-  K\ 
A  |=  c2\c2 

A  1=  Cl  c2  fr  {c'J a] k2 


App 


A  (=  ci  ft-  «i  A  |=  c2  ft  k2 
_  Record 

A  |=<  ci,c2  >ft  Ki  x  k2 


A  |=  c  fr  E(a  ::  «i).k2 
-  Projl 

A  (=  c.l  fr  «i 

A  ^  c  ft  E(ct ::  ki).k2  A  |=  c\c' 
-  Proj2 

A  (=  c.2  fr  {c,.1/q'}k2 

A  |=  Cl  fr  KiA[a  ::  *i]  (=  c2  fr  k2 
A  |=  ci\ci  a  £  Dom(A)  ^ 

A  let  a  =  ci  in  c2  end  ft  {ci/ a}«2 


Well-formed  Type 

Assume  A  is  well-formed.  Check  that  r  is  well-formed. 
A  |=  c  ft  T 

_  Constructor 

A  t=  T(c) 


A  f=  r 
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A  f=  k  A  (=  k\n 

A[g-::k]  |=  T\  A[q::k]  f=  ri\r{ 

A[»::k][.t  :  Tj]  r2  a  £  Dom(A) 

A  \=  (a  ::  k,  x  :  ri)  -4  r2 


Arrow  Type 


_  Float 

A  |=  Float 


A  |=  ti  A  |=  r2 

_  PairType 

A  f=  Ti  x  r2 


Type  Analysis 


A  |=  e  JJ-  r 


Note  that  we  restrict  this  to  core  types.  Assume  A  and  t  are  well-formed.  Check  that  e  is  well-typed, 
and  has  type  r. 


A  (=  e  f 1  r'  A  (=  t'  =  r 
A  (=  e  fl  r 


Analysis 


Type  Synthesis 


A  |=  e  fr  r 


Assume  A  is  well-formed.  Check  that  e  is  well-formed  and  construct  its  type  r,  such  that  A  f=  r 

_  variable 

A[x  :  r]  f=  x  ft  r 


A  |=  ej  f|*  Ti  A[x  :  ti\  \=  e2  i\  r2  x  £  Dom(A) 
A  f=  let  x  =  ei  in  e2  end  ft  7"2 


lete 


A  |=  c  ft  K  A  (=  c\c' 

A[a::ft]  [=  e  ft  r  a  ^  Dom(A) 

A  |=  let  a  =  cine  end  ft  {c'/a}r 


A  (=  /c  A  |=  Z:\ft 

A[a::ft]  A[q::k]  |=  ri\r{ 

A[cr::K]  |=  r2  A[a::«]  (=  r2\r^ 

A[<k:k][:e  :  r[][f  :  (a  ::  k,  t[)  t'2}\=  e  $  t'2 

f,x,a  4.  Dom(A) 

_  rec 

A  |=  rec  /  =  X(a::k ,  x  :  ti)  :  r2.e  -ft  (a  ::  k,  t[)  — ►  t2 


A  ci  fl  (o  ::  k,  ri)  r2  A  }=  c  fl  k 
A  |=  c\c '  A  |=  e2  fl  {c,/o'}ri 

A  |=  ei[c]e2  fl  {c'/ar}r2 
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A  (=  ei  ft  T(ce)  A  |=  ce  !-*•  Ci  -*  c2  A  |=  e2  ft  T(c!) 


Monomorphic  app 


A  1=  eiQe2  ft  T(c2) 

A  |=  ex  ft  Ti  A  1=  e2  ft  r2 
_  pair 

A  |=<  elte2  >ft  ri  x  r2 


A  |=  e  ft  ti  x  r2 

type.projl 

A  1=  e.l  ft  ri 

A  |=  e  f)*  T(c)  A  |=  c  h->  Ci  x  C2 

A  |=  e.l  ft  T(ci) 

A  [=  e  ft  T\  x  r2 

type_proj2 

A  \=  e.2  ft  r2 

A  |=  e  fr  T(c)  A  c  i-)-  ci  x  C2 

Ah  e.2  ftT(c2) 

float 

A  (=  r  Float 

.  int 

A  (=  n  ft  T(Int) 


con .pro jl 


con .pro j 2 


A  |=  e  ft  Float 

A  |=  boxfloat(e)  ft  T (Box Float) 


box 


A  |=  e  ft  T (Box Float) 
_  unbox 

A  h  unboxfloat(e)  ft  Float 


A  |=  e  ft  T(c)  A  \=  c  >->•  c\  +  c2 

A[x  :  T(ci  +1  c2)]  f=  ei  ft  rx  A[x  :  T(cx  +1  c2)]  \=  e2  ft  r2 

A  1=  ri  =  r2 

A  |=  casee  x  of  {inl(ej)  =>  e2,  inr(ei)  ^ftJ-Ti 


A  [=  ci  ft  T  A|=c2ftr 
A  (=  ci\c'x  A  \=  c2\c2 

AMg) _ 

A  M^ci.cjeftlftci+c^) 


ini 


sumswitch 
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A  \=cllT  A  \=c2^T 

A  |=  ci\cj  A  |=  c2\c2 

A\=el^T(c'2) 


mr 


A  (=  inrCl)C2e  1)  T(c[  +  c2) 

A\=  c  l)-T  A  \=  c\c' 

A  b  ci  JJ.  T(Int)  A\=e2\l  T(c’) 

_  array 

A  |=  arrayc(ei,  e2)  ff  T(c'  array ) 

A  (=  ei  fr  T(c)  A  [=  c  i-4  c'  array  A  |=  e2  JJ  Int 
_  sub 

A  (=  sub[e1](e2,fr)71(c') 

A  e\  JJ  T (Box Float  array)  A  (=  e2  JJ  T(Int) 
_  fsub 

A  (=  fsub(ei,e2)  ft  Float 

B.2  Termination  Proofs 
B.2.1  Proof  of  Lemma  7 

To  show:  SZ  is  order  preserving.  That  is,  Jj  -<  J2  =>  SZ(Ji)  <  SZ(J2)  where  <  is  the  lexicographic 
ordering  on  N  x  N. 

Proof.  The  proof  proceeds  by  cases  over  the  conclusion  of  J2,  demonstrating  that  each 
immediate  subderivation  is  strictly  smaller  according  to  the  given  metric.  We  ignore  subderivations 
that  correspond  to  judgements  which  are  independently  known  to  be  decidable,  such  as  subkinding 
and  constructor  equivalence.  Technically,  this  may  be  viewed  as  using  the  constant  measure  that 
always  returns  zero  for  these  judgements. 

•  Kind  standardization  A  |=  Ic\k 

Type  No  premises 

Singleton.Type 

SZ(A  (=  c\c')  =  (szc{c),  0) 

<  (szc(c)  +  l,0) 

=  SZ( A  |=  St{c)\St{c')) 

Singleton_Any 

SZ(A^cflK)  =  (s2c(c),0) 

<  (S2c(c)  +  1,0) 

=  SZ(A  |=  S(c)\k) 


Pi 
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1. 


5Z(A  |=  =  {szK(ki), 0) 

<  (szK(n(a: ::  An).*2),  0) 

=  SZ{ A  1=  n (a  ::  fc1).ifc2\n(a  ::  «i ).k2) 


SZ(A[a::Ki\\=  k2\K2)  =  (szK{k2),0) 

<  (s2«(n(a ::  ki).k2),0) 

=  SZ( A  |=  II(a  ::  fci).fc2\II(a  ::  ki).k 2) 

Sigma  As  with  the  Pi  case. 

•  Constructor  standardization  (All  cases  except  those  below  are  just  decomposition  of  the 
constructor) 

Lambda 


1. 

SZ(A|=*\k)  =  (szK(k),  0) 

<  (s2c(Aa::fc.c),  0) 

=  SZ( A  f=  \a::k.c\Xa::K.c') 

2. 

SZ{A[oc.:k\  \=  c\c')  =  («2c(c),0) 

<  (s2c(Ao;::A;.c),  0) 

=  SZ{ A  (=  Xa::k.c\Xa::K.c') 


Let  The  size  of  the  original  derivation  is 

SZ( A  |=  let  a  =  cx  inc2  end\let  a  =  c\  incj  end)  =  (s2c(ci)  +  szc(c2),  0) 


1. 


2. 


3. 


SZ{A  \=  ci\ci)  =  (s2c(ci),0) 

<  (s*c(ci)  +  S2c(c2),0) 


SZ( A  |=  ci  k)  =  (s2c(cx),  0) 

<  (S2c(ci)  +  S2c(c2),0) 


SZ(A[a::«]  [=  c2\c'2)  =  (s2c(c2),0) 

<  (s2c(c2)  +  S2c(ci),0) 
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•  Well  Formed  Kind  A  [ =  k 

Type,  Singleton_Type  As  before 
Singleton_Any 

SZ(A^cfTK)  =  (szc(c),0) 

<  (S2c(c)  +  1,0) 

=  SZ{A\=S{c)) 

Pi 

1. 

SZ( A  Mi)  =  (sz^h),  0) 

<  {szK(ki)  +  szK(k2),  0) 

=  SZ(A  (=  II(a  ::  ki).k2) 

2. 

SZ{A[a::Ki]  \=  k2)  =  (szK(k2),0) 

<  (szk(Ai)  +  szK(k2),  0) 

=  SZ(A  (=  II(a  ::  ki).k2) 

Sigma  As  with  the  Pi  case. 

•  Kind  Analysis  remains  unchanged. 

•  Kind  Synthesis  A  (=  c  ft  k 

Variable  By  lemma  4.  Note  that  kinds  in  the  context  are  restricted  to  the  core  syntactic 
forms. 

BoxFloat  No  premises 
Int  No  premises 

H  Let  k  =  ST{v{ a,P).{c'vc'2).\)  x  ST(n{at,  0).{c\,  c'2).2) 

1. 

SZ(A[a::T][(3::T]  \=  a  ^  T)  =  («ze(c,),  1) 

<  (szc(ci)  +  52c(c2),0) 

=  (szc(n(a  =  cj,fe=  c2)),0) 

=  SZ(A  \=  n(a,(l).(ci,c2)  ft  k) 

2. 

SZ(A[or.:T)[(3::T]\=cM)  =  («c(ci),0) 

<  (sac(ci) +  sac(c2),0) 

=  (szc(/i(o,j8).(c1,c2)),0) 

3.  The  cases  for  c2  are  exactly  the  same. 
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Pair 


1. 

SZ(A\=Cl^T)  =  (szc(ci),l) 

<  (S^c(ci)  +S2c(C2),0) 

=  («2c(Ci  X  C2),0) 

=  SZ( A  [=  ci  x  C2  f|-  St{c'i  x  c'2)) 

2. 

5Z(Af=cj\ci)  =  (s2c(ci) ,  0) 

<  («2c(ci)  +S2c(c2),0) 

=  SZ( A  (=  ci  x  c2  ft  5t(ci  x  c'2)) 

3.  Similarly  for  the  c2  premises. 

Arrow  As  with  the  Pair  case. 

Sum  As  with  the  Pair  case. 

Array 

1. 

SZ(A\=cl^T)  =  (s2c(c),l) 

<  (S2c(c)  +  1,0) 

=  (szc(c  array),  0) 

=  SZ( A  (=  c  array  ft  5j(c  array)) 

2. 

SZ{A  |=  c\c')  =  (szc(c),0) 

<  (szc  (c)  +  1,0) 

=  SZ( A  (=  c  array  ft  d  array) 

Lambda 

1. 

SZ{A\=k)  =  (szK(k),  0) 

<  (szK(k)  +  szc(c),0) 

=  (szc(Xa::k.c),  0) 

=  SZ(A  (=  Xa::k.c  ft  Il(a  ::  k).k') 

2. 

SZ(A\=k\K)  =  (s2kW,0) 

<  (s2c(Aa::A;.c),0) 

=  SZ(A  |=  Aa::A;.cfrn(a  ::k).k') 

3. 

SZ(A[a  ::  k]  |=  c  ft  n1)  =  (szc(c),  0) 

<  (s2c(Aa::A:.c),  0) 

=  SZ(A  f=  Xav.k.c  ft  II(a  ::  k).k') 
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App 

1. 

5Z(A  (=  Cj  fr  n(Q  ::  K!).K2)  =  (s2c(d),0) 

<  (s-Jc(ci)  +  szc(c2),  0) 

=  (S2c(ClC2),0) 

=  SZ{A  f=  Cl  c2  fr  {4/of}K2) 

2. 

SZ(A\=  c2  ki)  =  (S2c(c2),l) 

<  (®2c(Ci  C2) ,  0) 

=  SZ(A  f=  Cl  c2  ft  {c2/o}k2) 

3. 

SZ(Af=c2\c'2)  =  (s2c(c2),0) 

<  (S2c(CiC2),0) 

=  SZ(A  |=  Cl  c2  f|-  {c2/»}k2) 

Record  As  before 
Projl  As  before 
Proj2 

1. 

SZ(A  |=  cfr£(a  ::  *i).k2)  =  (s2c(c),0) 

A  <  (szc(c)  + 1,0) 

=  (S2C(C.1),0) 

=  SZ(A  (=  c.l  fr  {c'.1/o}k2) 

2. 

SZ (A  (=  c\c')  =  (szc(c),  0) 

<  (S2c(c.l),0) 

=  SZ(A  |=  c.l  fr  {c'.1/o}k2) 

Let 

1. 

sz(a  (=  ci  fr  «i)  =  Kfco.o) 

<  (S2c(ci)  +S4Tc(c2),0) 

=  (s2c(let  a  =  ci  in  c2end),  0) 

=  SZ( A  (=  let  o  =  ci  in  c2  end  fr  {c\/o)k2) 

2. 

SZ(A[a  ::  Kj]  (=  c2  fr  k2)  =  (szc{c2),  0) 

<  («2c(ci)  +  szc(c2),0) 

=  (sarc(leto  =  ci  inc2end),0) 

=  SZ(A  |=  let  a  =  Ci  in  c2  end  fr  {c\/a}K2) 


44 


3. 


5Z(A  f=  ca\ci) 


(szc(let  a  =  c\  in  C2  end),  0) 

SZ( A  |=  let  a  =  c\  inc2  end  ff  {c^/o^k 2) 
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